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1 .0 Executive Overview 

The purpose of this deliverable is to specify the requirements of the Virtual 
Sample Closet (VSC) system that MPI_2.COM will build for MedManage. The 
VSC Web application will accept data from a variety of sources related to 
pharmaceutical sample disbursement. The system also will store and provide 
extracts of the data, prepare a set of standardized reports, and enable system 
users to request and authorize additional vouchers for delivery to appropriate 
entities. 

This Functional Requirements document details the scope of work and timeline 
that MPL2.COM is committed to for Release 1 .0 of the VSC. To meet this 
obligation, the requirements of the system, as detailed in this document, must 
remain constant. However, as issues arise throughout the project MPL2.COM will 
consider modifications to the system requirements, as long as the overall scope 
of work does not change. 

The requirements in this document supersede any functional requirements 
previously stated in the Contract or Discovery documents. Follow-on releases of 
the system will be defined in separate requirements documents. 

1.1 Background 

^eDiscovery phase of the MedManage VSC project began on|^| | 
J p During this phase, MPL2.COM interviewed MedManage executives and 
consultants, analyzed relevant information presented by MedManage, and 
developed a set of functional requirements for the VSC system. The results are 
summarized in this document. 

MedManage is revolutionizing the pharmaceutical sample distribution process by 
substituting the use of a voucher system for the traditional process of physicians 
distributing physical samples to patients. With the new system, physicians will 
issue vouchers to patients. To obtain product samples, patients present the 
vouchers at pharmacies, where information about the patient, his physician, and 
his health care organization is captured. This information is forwarded to 
MedManage, who will provide utilization information to pharmaceutical 
companies and health care organizations. 

The voucher tracking and reporting system can be considered a Virtual Sample 
Closet. Pharmacies are indirectly involved in the MedManage system, and do 
not at this time utilize the backend system. Groups who will actively use the 
system include pharmaceutical manufacturers, voucher fulfillment vendors, 
pharmaceutical sales representatives, medical records companies, medical 
partner Web sites, and other possible entities. 
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Utilization information about samples will be extracted from the VSC and 
provided to health care organizations and pharmaceutical companies. 
MedManage will support the operational aspects of the system, such as 
collecting, storing and extracting data, as well as providing an infrastructure to 
manage operational tasks associated with the system. 

1.2 System User Roles 

1.2.1 MedManage 

MedManage provides vouchers to pharmaceutical companies, records utilization, 
bills customers accordingly, operates the Virtual Sample Closet application and 
provides data extracts to customers from the VSC. 

1 .2.2 Health Care Organization 

Health care organizations provide vouchers to patients (through physicians in 
their employ), and receive data extracts or reports from MedManage. Health care 
organizations can have a variety of authorized users. 

1.2.3 Physician 

Physicians dispense vouchers to patients. Physicians (and other authorized 
users) also request additional vouchers through the VSC system. 

1.2.4 Pharmaceutical Sales Representatives 

Pharmaceutical Sales Representatives visit with physicians, and authorize 
release of additional vouchers. A Sales Representative may receive a set of 
standard utilization reports or a physician utilization report when a physician 
requests additional vouchers. 

1 .3 Audiences 

The audience for this document includes the following groups. 



1.4 Project Roles and Responsibilities 

MedManage is responsible for providing all business rules, information about 
system interface requirements, and for designing templates for data reports and 
pivot tables. 

MPL2.COM is responsible for gathering and documenting requirements, 
developing an application and information architecture, and providing assistance 
in reviewing networking and hardware architecture. 



Client: 

Project Management: 
Development: 



MedManage 

MPL2.COM 

MPL2.COM 
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Project Manager 

Application Architect 

Database Designer 
Business Analyst 

Information Architect 

Information Designer 
Graphic Designer 



Manages daily operations of project and coordinates 
technical resources, and manages scope of project. 

Responsible for overall design of the application 
architecture. 

Prepares the logical and physical database designs. 

Sets the direction and scope of the project together 
with MedManage. 

Analyzes users' information requirements and 
develops a framework for user interaction with the 
system. 

Applies layout and functionality to information 
architecture. 

Develops visual designs to reflect client's branding 
and marketing goals. 



1 .5 Assumptions 

MedManage will define specific network architecture and security level 
requirements for the VSC system. 
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2.0 Functional Requirements 

This section specifies requirements for Release 1.0 of the MedManage Virtual 
Sample Closet (VSC) Web application. The Virtual Sample Closet has three 
major sections: capture data, extract data and process orders for new vouchers. 

Data capture requirements concentrate on importing information about voucher 
redemption at pharmacies, as well as importing source lists for physicians, health 
care organization locations, pharmaceutical company sales organization and 
product information, and pharmacy location information. 

Information extract requirements focus on extracting voucher utilization 
information filtered by company or health care organization, creating product 
utilization reports by a specific physician who is requesting more vouchers, and 
providing a small set of standard reports. 

The voucher order processing section will accept requests for vouchers, 
authorize the release of vouchers, notify pharmaceutical company administration 
and sales reps when physicians request additional vouchers, and notify 
pharmaceutical company administrations when allotments have declined to a 
specified level at a health care or physician location. 

2.1 Data Import and Standardization Requirements 

This section summarizes VSC data capture functions and file standardization 
requirements. 

2.1 .1 Import pharmacy voucher-utilization data files 

This function accepts information from several standardized databases, reads 
raw data from pharmacy vouchers, and performs data cleansing and rule 
validation on the data before importing the data into the VSC main database. 

This information is to be provided by Med Impact. In the future, there may be 
other data aggregators. 

2.1.2 Import and standardize pharmaceutical product information 

This function imports data files containing information about products and 
product codes into the Pharmaceutical Product Information database. This 
function will be controlled by MedManage. 

2.1.3 Import pharmaceutical sales and marketing structure information 

This function imports a structured file containing information about companies 
and their sales management organization and territory information and places it 
into the Pharmaceutical Organizational Structure database. 
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2.1 .4 Import and standardize physician information 

This function imports raw data files containing information about physicians and 
their ME ID number before placing the data into the Standardized Physicians 
database. It is expected that HCOs will provide this file during HCO customer 
initialization of the MedManage system. 

2.1 .5 Import and standardize health care organization (HCO) information. 

This function imports HCO raw data files and standardizes the data before 
placing it into the Standardized HCO Location database. 

2.2 Data Extract and Reporting Requirements 

MedManage will not support database reporting on its servers. MedManage will 
provide data extracts to health care organizations (HCOs) and pharmaceutical 
companies. The VSC will extract each customer's data, package it and then 
forward the extracts to the customer. 

A select set of standard reports will be available, including: 

• Utilization History Reports for Sales Reps 

• Utilization Reports by history, sales region, and/or drug 

2.2.1 Provide a set of standard reports on a regular basis. 
This function runs reports on a specified schedule. 

2.2.2 Provide data extracts to customers of only that customer's data 

This function provides standard data extracts of voucher utilization records, 
filtered by customer. A customer receives only the information to which he is 
entitled. 
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2.3 Use Cases 

This section summarizes use cases for: 

• Voucher requests 

• Voucher request approval 

• Voucher order status 

• Pharma Admin product information management 

• HCO user management 

• Doctor profile self-management 

• Client management 

• Pharma Sales Rep management 
See Appendix D - Use Case Diagrams. 

2.3.1 Voucher requests 

This function enables users (HCO personnel, pharma admins or sales reps) to 
request additional vouchers. This function should allow an HCO to search for all 
MedManage products available in the system, in addition to only seeing those 
products available by contractual agreement. The process will also provide for 
distributed fulfillment destinations. 

• Login 

• Search 

• View search results 

• Select product/voucher 

• Select fulfillment destination 

• Review/confirm order 

• Logout 

See Appendix D - Use Case Diagrams. 

2.3.2 Voucher request approval 

This function will display a pending list of open voucher requests that a user is 
qualified to view, and release voucher request information to Fulfillment. 

Note: System will mark as completed the voucher request order, and adjust the 
voucher stock level in the appropriate territory. 

Note: System will escalate pending order to specified designee if order is not 
acted upon within a specified number of days from request being entered. 

Note: All voucher requests and associated transactions (authorize, deny, etc.) 
will have a unique transaction number. 

Voucher approval process: 
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• Login 

• View list of pending orders 

• Select order 

• Display information 

• Logout 

See Appendix D - Use Case Diagrams. 

2.3.3 Voucher order status 

Displays pending list of open voucher requests that a user is qualified to view. 

Note: All voucher requests and associated transactions (authorize, deny, etc.) 
will have a unique transaction number associated with the transaction. 

Status display process: 

• Login 

• View list of pending orders 

• Batch approve or select order 

• Processes Order 

- Approve 

- Deny 

- Modify 

• Logout 

2.3.2 Product information management 

This function enables an authorized user (MedManage) to administer a 
company's product information in the Pharmaceutical Product Information 
database. 

Product information process: 

• Login 

• Create, modify or delete product information 

• Confirm changes 

• Logout 

See Appendix D - Use Case Diagrams. 

2.3.3 HCO user management 

This function allows a health care organization to edit its user profiles. 

HCO user management process: 

• Login 

• Create, modify or delete profile 

• Confirm changes 

• Logout 

See Appendix D - Use Case Diagrams. 



MPL2.COM Sav8cggaag32 PM) 



9 



Confidential 



Version 1 .2 



Functional Requirements 



2.3.4 Doctor profile self-management 

This function allows independent physicians to modify their user profiles. 

Doctor profile management process: 

• Login 

• Modify 

• Confirm changes 

• Logout 

See Appendix D - Use Case Diagrams. 

2.3.5 VSC Client management 

This function allows MedManage to create profiles for new doctors, health care 
organizations, and pharmaceutical companies within the MedManage system. 

Initialization process: 

• Login 

• Create, modify or delete profile 

• Confirm changes 

• Logout 

See Appendix D - Use Case Diagrams. 

2.3.6 Pharma sales organization management 

This function allows a pharmaceutical company to manage sales territories and 
assign sales reps to defined territories. A territory is defined by a drug and/or zip 
code and/or HCO entity combination. Sales reps are assigned to a territory. 

Sales organization management process: 

• Login 

• Select sales territory 

• Create, modify, inactivate 

o Set drug, zip code, HCO parameters 

• Select sales rep 

• Create, modify, inactivate 

o Set territory parameters 
o Set profile parameters 

• Confirm changes 

• Logout 

See Appendix D - Use Case Diagrams. 
See Appendix D - Use Case Diagrams. 
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2.4 VSC System Requirements 

2.4.1 Validate user access permissions and logon 

This function validates user permissions, finds user's profile in the database and 
validates login request. Transfers control to next step or rejects logon attempt 
and returns to logon screen. 

2.4.2 Process voucher requests 

This function performs data lookup using manufacturers' product category tables 
and creates an entry in the "shopping baskef when the user selects a voucher or 
product. The user is returned to the search function when an item is not found in 
the database. The function creates confirmation screens to enable users to add, 
delete, or commit orders. 

When a request transaction is initiated the system parses the transaction by 
manufacturer and/or sales representative and places voucher orders in a 
pending order table. 

The user receives a confirmation that the order went through. The confirmation 
may be via a response screen or e-mail. 

A Pharma sales representative will receive notification via e-mail, pager, 
telephone, or other contact method set up in his profile. The setup of these 
parameters is handled when a sales rep is assigned to a territory. 

If a voucher is requested from a Pharma that has no valid representative for the 
territory, the request is sent to the default Pharma administrator or the territory 
manager. This is an escalation issue. 

2.4.3 Voucher Approvals/Denials 

The system will escalate voucher approval to the sales representatives manager 
if a request is not processed within a specific time period. 

The limit threshold may be configured by individual representatives, with an initial 
system default of five days. 

A voucher denial will trigger immediate notification of the sales representative's 
manager. 

2.4.4 Notify pharmaceutical personnel when voucher inventories reach a preset level 

This function compares voucher usage with allocated territory levels, and notifies 
pharma admin and sales representatives that additional vouchers should be 
delivered to an HCO or physician location. 
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2.4.5 Create a new customer's pharmaceutical database 

This function allows MedManage to set up a new company in the pharmaceutical 
information database. The system will create the necessary tables assigned to 
the pharma. These tables could include lists of products, sales representatives, 
and sales territory definitions. Multiple sales reps can be assigned to one 
territory. 

Sales territories can be defined by: 

• Zip code 

• Product line 

• HCO Entity 

2.4.6 Preserve inactivated records 

The system will keep inactivated records for up to thirty days before removing 
them from the system. This is an archival function. Purged records are removed 
from the database and moved to offline storage. 

Note: This is a MedManage system admin function. The system will notify the 
system admin via reminders, or simply archives purged records monthly. Final 
functional specification TBD with MedManage input. 

3.0 User Interface Requirements 

3.1 Graphic Design 

The look and feel of the graphical interface will reflect the corporate branding 
guidelines of MedManage. 

3.2 Usability Requirements 

The Ul will maximize the intuitive quality of the interface, define the logical 
relationship between content elements, distinguish between user actions on the 
site, and make the functionality apparent to users. 

4.0 Performance Requirements 

None specified by MedManage. 
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5.0 Application Architecture Requirements 

The application will use the following: 

• Windows 2000 Server operating system 

• SQL 7.0 database 

• IIS 5.0 web server 

• ASP (Active Server Pages) dynamic web pages. 

• The system will support the following client platforms for browsers 

- Windows 95/98 

- Windows NT 4 Workstation & Server 

- Windows 2000 Professional & Server 

- Apple Macintosh 

The Browser supports MS Internet Explorer 4.0 and later, Netscape 4.0 and later, 
and AOL 4.0 and later. 
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6.0 Security Requirements 

There are security requirements for the VSC system. The internal web site will 
be available to anyone with general access to the MedManage intranet. Also, 
since the system will be hosted and maintained by MedManage, they will be 
responsible for system security. 

6.1 Application Security 

Users will only have access to features of the VSC that are permitted by their 
logon permission level. 

This function must include an authentication/authorization mechanism that 
prevents patient information from being viewed by pharmaceutical companies, 
sales representatives, MedManage employees, or any other unauthorized user. 

Personnel from pharmaceutical companies may view only data extracts for the 
company they represent. 

In addition to application security in real-time, the system will have the 
capabilities to provide audit tracking of transactions. 

6.1 .1 Voucher Serial Number 

The system will provide unique serial numbers on each voucher printed from the 
MedManage system. (For future use. Build into system and data model in 
Phase I). 

6.1 .2 Audit Transaction Tracking 

The system will record transactions by users in a log to provide an audit trail. 
The transactions recorded will track voucher requests, voucher releases and 
additions or changes to authorized user lists in pharmas and HCOs. 
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Appendix A - Glossary of Terms 



HCO 



Health Care Organization 



NABP 



National Association of Board of Pharmacists 

NABP produces a unique code for each pharmacy, two digit state code + 5 digits 

PhRMA (or Pharma) 

Pharmaceutical Research & Manufacturers of America. Also an industry term for 
pharmaceutical company. 

Standardization 

Changes raw data entry information to match a specified, consistent format. 
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Appendix D - Use Case Diagrams 



> Voucher requests 

> Voucher approval 

> Voucher order status 

> Product information management 

> HCO user management 

> Doctor profile self-management 

> Client management 

> Pharma Sales Rep management 
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Use Case= Entity 
Voucher 
Requests 



^ Entity Logs OrT ^ 



Browse for product 



Select a product 



Select voucher 
quantity 



Yes 



Select fulfillment 
destination 



Add to order 
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Use Cases 
Voucher Request 
Approval 



(harma/Sales Repv 
Logs On J 



Batch Approve 



1 

View list 
pending 


of orders 
approval 






Select Order 






Process Order 



Yes 




Provide 
explanation of 



Confirm 4- 



No 

JL 



^ Return ^ 



Approve orders 




Deny orders 




Modify order 




-Yes' 
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Use Case= Entity 
Voucher Order 
Status 



^ Entity logs on^ 



Yes 



1 


r 


Display pending 
orders ^ 




r 


Select an order 






Display status and 
other information 




r 



No 




Entity Logs Out 
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Use Case= 

Product 
Information 
Management 
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Use Case= 
HCO User 
Management 



^ HCO Logs On^ 




Create new 
user record 



Find an 
existing record 

(Modify. Inactivate) 



Modify 



inactivate 




Yes 
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Use Case= 
Doctor Profile 
Self Management 




Yes 



1 


r 


Confirm 




r 



^Doctor Logs Off 
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Types of Clients 

MedManage clients 

are one of three 

types: 

-Pharma 

-HCO 

-Doctor 



Select client type 
(Pharma, HCO, MD) 



Use Case= 
MedManage 

Client 
Management 




Find an 
existing record 

(Modify. Inactivate) 



Create 
client record 











Inactivate 



Yes 



XT Review 



Yes 



Confirm 
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Use Case* 
Pharma Sales 
Organization 
Management 
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Use Case: Entity Request Vouchers 



information Flow: 

I 

1 . User begins process%ith username and password. 

2. User- selects a product either by browsing an alphabetized list of all products, or by searching on at 
least one of the following criteria: 

• Generic name 

• Trade name 

• Therapeutic class by description 

• Manufacturer 

3. User selects a product. 

4. User selects a voucher quantity. 

5. User adds selected product and quantity to order. 

6. User decides whether or not to select more products: 

• If yes, user can return to original result set, execute a new search, or browse product list. Iterative 
loop continues until order is complete. 

• If no, user proceeds. 

7. User reviews order and confirms. User can change shipping address here: 

• If order is correct, user ends process. 

• If order is incorrect, user makes appropriate changes and ends process. 
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Use Case: 



Use Case= 
Entity Voucher 



(Entity Begins A 
Process J 



Search for product 



Select a product 



Select voucher 
quantity 



Yes 



Add to order 



Yes 
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Use Case: Pharma Voucher Approval 



Information Flow: 

The following steps are taken to determine whether a Pharma will batch approve or individually approve 
request: 

1 . Pharma begins process with username and password 

2. Pharma views voucher requests (orders) pending approval. Details shown for each order include: 

• HCO 

• Name of requester 

• Date requested 

• Name of person receiving vouchers 

• Address and phone number of person receiving vouchers 

• Name and quantity of products requested 

3. Pharma decides whether to batch approve orders or approve orders individually. 

BATCH APPROVE 

Pharma decides to batch approve orders: 

1 . The Pharma sees a warning if they are approving a quantity of vouchers that exceeds a set limit. 

2. The Pharma must be able to print the orders they've batch approved. 

3. Once batch approval is complete, the Pharma ends process. 



APPROVE ORDERS INDIVIDUALLY 

Pharma decides to approve orders individually: 

1 . Select order. 

2. Choose Process order (see process order information flow). 

3. Decide whether or not to process more orders: 

• If yes, return to select order. 

• If no, end process. 

The following steps are taken to determine when a Pharma decides whether to approve, deny, or 
modify an order: 

APPROVE 

To approve an order: 

1. Select approve. 

2. Confirm: 

• If yes, Pharma returns to selecting orders in the Voucher Approval process. 

• If no, Pharma returns to order. 

DENY 

To deny an order 

1 . Select deny. 

2. Provide an explanation of denial. 

3. Confirm: 

• If yes, Pharma returns to selecting orders in the Voucher Approval process. 

• If no, Pharma returns to order. 



MODIFY 

To modify an order: 

1 . Select modify. 

2. Make modifications to quantity requested only. 
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3. Provide explanation of modification. 

4. Confirm: 

• If yes, Pharma returns to selecting orders in the Voucher Approval process. 

• If no, Pharma returns to order. 




View list of orders 
pending approval 




Use Case: Entity Pending Order 



Information Flow: 

1 . Entity begins process. 

2. Entity locates order by date requested. 

3. Entity selects order. 

4. Entity views order status. 

5. Entity decides whether or not to view more orders: 

• If yes, entity returns to searching for an order. 

• If no, entity ends process. 



Use Case: 



Use Case= Entity 
Pending Order 



(Entity Begins A 
Process J 



Browse for order 



Select an order 



Yes 



View status of 
order 
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Use Case: Pharma Product Information Management 

Information Flow: 

Pharma users can add marketing information to a product or modify product information. 

Steps for MM User to add marketing information or to modify product information: 

1. Pharma User begins process with username and password. 

2. Pharma User locates a product by its trade name. 

3. Pharma User decides whether to add marketing information or to modify product information. 
ADD 

The following marketing information is required: 

• Company logo (upload) 

• Pharmaceutical product logo (upload) 

• Cover pad graphics 

• Pharmaceutical product Web site URL 

• Tag lines (up to 4 allowed) 

Pharma User reviews record: 

• If everything is correct, Pharma User confirms. 

• If modifications are necessary, Pharma User modifies record. 

Pharma User decides whether to add marketing information to more products: 

• If yes, return to selecting a product. 

• If no, end process. 



MODIFY 

The following steps are taken to modify product information: 

1 . Pharma User locates a product by its trade name. 

2. Pharma User can modify these fields in a product record: 

• Maximum quantity allowed. 

3. Pharma User reviews record: 

• If everything is correct, Pharma User confirms. 

• If modifications are necessary, Pharma User modifies record. 

4. Pharma User decides whether to modify more records: 

• If yes, return to selecting a product record. 

• If no, end process. 
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Use Case: 



Use Cases 
Product 
Information 
Management 




Creale 



Rnd (Modify, 
Inactivate) 



Modify 



Inactivate 




Yes 
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Use Case: Doctor Profile Self Management 

Information Flow: 

1 . Doctor begins process. 

2. Doctor selects "update profile 0 option. 

3. Doctor makes modifications to profile. All fields can be modified except ME# and DEA. 

4. Doctor reviews profile: 

• If changes are necessary, doctor returns to profile to make necessary modifications. 

• If changes are acceptable, doctor confirms. 

5. Doctor ends process. 

Use Case: 



Use 
Doctor Profile 
Self Management 



(Doctor Begins A 
Process J 







Modify 







No 




9 



Use Case: MedManage Client Management 

Information Flow: 

1. MM user begins process with usemame and password. 

2. MM user decides whether to create , modify , or inactivate client records. 

3. MM user selects client type from the following: 

• Pharma 

• HCO 

• Doctor 



CREATE 

To create a new client record, the steps are different for Pharma and HCO/Doctor : 



PHARMA 

To create a Pharma record, the following information is required (see below for details on each): 

1. General 

2. Voucher Claims Processing 

3. Manufacturer 

4. Financial 

5. Claims Data Reporting 

6. Vendor Storage and Distribution 

Once these 6 steps are completed, MM enters product information for this Pharma. 

• See Pharma Product Info Management Use Case. 

1 : General 

Enter the following general information: 

• Contract number 

• Date contract signed 

• Effective date of contract 

• Dispensing fee 

• Voucher fee 

• Advance payment amount 

• Cost of drug (percentage of AWP) 



2: Voucher Claims Processing 



Voucher claims per billing cycle 


Per processed Voucher/Claim electronically submitted 


Less than 250, 000 




250, 001-500, 000 




500,001-800,000 




800,001-1,000,000 




1,000, 001 -plus 





3: Manufacturer 

The following information is needed about the manufacturer: 
1 . Enter the following manufacturer information: 

• Corporate name (as it should appear on contract) 

• Corporate address 

• City 

• State 
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• Zip 

• Phone 

• Web site 

• Primary Contact 

• Title 

• Address (if different from above) 

• City 

• State 
. Zip 

• Phone 

• Fax 

• Email 

2. Then select a Type of Business: 

• MedSample--AN HCO participation 

• MedSample-HCO specific (List name of each HCO if this choice is selected.) 

• MedSample-Custom Manufacturer Program 

4: Financial 

Enter the following financial information: 

• Primary Contact 

• Title 

• Phone 

• Fax 

• Email 

• Address for Invoices 

• City 

• State 
. Zip 

5: Claims Data Reporting 

The following steps are needed for Claims Data Reporting: 

1 . MedSample Standard Reports (select from the following) : 

• Group utilization-Physican data by group 

• Pharmacy utilization-Pharmacy data by network 

2. Custom Reports (enter up to 8 descriptions) 

3. Format (select from the following) 

• Zip 

• CD 

• Download 

• Paper (if selected, ship-to address must be provided) 
6: Voucher Storage and Distribution 

Please provide the following information about where the vouchers will be stored and distributed from: 

1 . Where will vouchers be stored? (select one of the following): 

• MM distribution center 

• Pharma distribution center 

• Mfg. Representative home/storage 

• HCO 

2. Physical Location: 

• Address 

• City 

• State 

• Zip Code 

• Phone 

• Fax 

• Email 
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• Primary Contact 

• Title 



Once all of the above information is complete, MM enters product information for this Pharma. See 
Pharma Product Info Management Use Case. 



HCO and DOCTOR 

To create a HCO or DOCTOR records, the following information is required (see below for details on 
each): 

1. Corporate Demographics 

2. Contacts 

3. Sales Collateral 

4. Drug Sample Formulary 



1: Corporate Demographics: 

The following information is required for creation of HCO or doctor records: 

• Name of organization 

• Address 

• Phone 

• Fax 

• Web site 

• # of physicians 

• # of clinics/sites 

• # of lives 

• Date samples are locked out 

• Date set for MedSample rollout 

• Clinic Sweep date 

2: Contacts 

The following contact information is required to create new HCO or doctor records: 

1. Primary 

• Name 

• Title 

• Phone 

• Fax 

• Email 

2. Pharmacy Director 

• Name 

• Title 

• Phone 

• Fax 

• Email 

3. Medical Director 

• Name 

• Title 

• Phone 

• Fax 

• Email 

4. Accounts Payable 

• Name 

• Title 

• Phone 

• Fax 



• Email 

5. Information Technology 

• Name 

• Title 

• Phone. 

• Fax 

• Email 



3: Sales Collateral 

The following information is needed for sales collateral: 

• Contact Person 

• Title 

• Phone 

• Fax 

• Email 

Mail-to information must be specified: 

• Collateral Mailed To (must be street address, no PO Box) 

• Address 

• City 

• State 

• Zip 



Sales Collateral 


Quantity Requested | 


Announcement cards 




Posters 




Display boxes 




Patient brochure 




Prescriber instructions 





4: Drug Sample Formulary 

MM user enters the following information for all drugs requested by the HCO: 

• 5-4-2 sequence 

• Trade name 

• Generic name 

• Therapeutic class code 

• Therapeutic class phrase 

• Form 

• Strength 

• Comments 



MODIFY 

To modify a client record 

1 . MM user locates record by client's name or the contract number. 

2. The following fields can be modified: 

3. MM user reviews modifications: 

• If more modifications are necessary, MM user returns to record and makes modifications. 

• If modifications are correct, MM user confirms changes. 

4. MM user decides whether or not to modify more records: 

• If yes, MM user returns to finding a record. 

• If no, MM user ends process. 
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INCATIVATE 

To inactivate a client record 

1 . MM user locates record by client's name or the contract number. 

2. MM user selects inactivate. 

3. MM user reviews inactivation: 

• If yes, MM user confirms inactivation. 

• If no, MM user returns to locating a product. 

4. MM user decides whether or not to inactivate more records: 

• If yes, MM user returns to finding a record. 

• If no, MM user ends process. 
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Use Case: 



Types of Clients 

MedManage clients 

are one of three 

types: 

-Pharma 

-HCO 

-Doctor 



Use Cases 
MedManage 

CI lent 
Management 



(MM Begins *N 
Process J 




Select cDent type 

(Pharma, HCO. MD) 




1 


> 




Create 
cfient record 






H 



Fmd an 
existing record 

(ModHy.b 



Modify 



Inactivate 




Yes 
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Use Case: MedManage Product Information Management 

Information Flow: 

MedManage (MM) User can create, modify, and inactivate pharmaceutical product information. 

Steps for MM User to create, modify, or inactivate information: 

• MM User begins process with usemame and password. 

• MM User decides whether to create, modify, or inactivate a product record. 

CREATE 

To create a product record, the following product information is required: 

• 5-4-2 code 

• Trade name 

• Generic name 

• Therapeutic class code 

• Therapeutic class phrase 

• Form 

• Strength 

• Maximum quantity allowed 

• Average wholesale price 

• Status 

• Order limit 

MM User reviews record: 

• If everything is correct, MM User confirms. 

• If modifications are necessary, MM User modifies record. 

MM User decides whether to create more records: 

• If yes, return to creating a record. 

• If no, end process. 

MODIFY 

To modify an existing record, take the following steps: 

1 . MM User locates a product by its trade name. 

2. MM User can modify these fields in a product record: 

• Maximum quantity allowed 

• Average wholesale price 

• Status 

• Order limit 

3. MM User reviews record: 

• If everything is correct, MM User confirms. 

• If modifications are necessary, MM User modifies record. 

4. MM User decides whether to modify more records. 

• If yes, return to selecting a product record. 

• If no, end process. 

INACTIVATE 

To inactivate an existing record, take the following steps: 

1 . MM User locates a product by its trade name. 

2. MM User can inactivate a product. No fields can be deleted. 

3. MM User reviews inactivation: 

• If the inactivation is confirmed, MM User either ends the process or selects another 
product. 
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• If the MM User does not want to inactivate the product, the MM User cancels the 
inactivation then ends the process or selects another product. 



Use Case: 



MedManage 

Product 
Information 
Management 




Yes 
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Use Case: HCO Location Management 

Information Flow: 

An HCO User can create, modify, or inactivate clinic records. 
CREATE 

To create a clinic record, the following information is required: 

• Clinic name 

• Address 1 

• Address 2 

• City 

• State 
. Zip 

• Phone 

• Fax 

• Sampling Admin Contact Name 

• Sampling Admin Contact Phone 

• Sampling Admin Contact Fax 

• Sampling Admin Contact Email 

HCO User reviews the record: 

1 . If everything is correct, HCO User confirms. 

2. If modifications are necessary, HCO User modifies record. 



HCO User decides whether to create more records: 

• If yes, return to creating record 

• If no, end process 



MODIFY 

To modify an existing record, HCO User locates a clinic by its name: 

1 . HCO User can modify any field in a clinic record. 

2. HCO User reviews record: 

• If everything is correct, HCO User confirms. 

• If modifications are necessary, HCO User modifies record. 

3. HCO User decides whether to create more records: 

• If yes, return to creating record. 

• If no, end process. 

INACTIVATE 

To inactivate an existing record, HCO User locates a clinic by its name. 

1 . HCO User can inactivate a clinic - no fields can be deleted. 

2. HCO User reviews inactivation: 

• If the inactivation is confirmed, HCO User either ends the process or selects another 
clinic. 

• If the HCO User does not want to inactivate the clinic, the HCO User cancels the 
inactivation then ends the process or selects another clinic. 
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Use Case: 



Use Case= 
HCO Locations 
Management 



(HCO Begins 
Process 




1 



Find 

(Modify. Inactivate) 




Create 



Modify 



Inactivate 
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Use Case: HCO Physician Management 

Information Flow: 

An HCO can create, modify, or inactivate physician records. 
CREATE 

To create a physician record, the following information is required: 

• Physician Name 

• Specialty 

• DEA 

• ME# 

• Clinic 

HCO reviews record: 

• If everything is correct, HCO confirms. 

• If modifications are necessary, HCO modifies record. 

HCO decides whether to create more records: 

• If yes, return to creating a record. 

• If no, end process. 



MODIFY 

To modify an existing record, HCO locates a physician by name or by clinic. 

1. HCO can modify Name, Specialty, and Clinic in a physician record. 

2. HCO reviews record: 

• If everything is correct, HCO confirms. 

• If modifications are necessary, HCO modifies record. 
1 . HCO decides whether to modify more records: 

• If yes, return to selecting a clinic record. 

• If no, end process. 

INACTIVATE 

To inactivate an existing record, HCO locates a physician by name or by clinic. 

1 . HCO can inactivate a physician. No fields can be deleted. 

2. HCO reviews inactivation. 

• If the inactivation is confirmed, HCO either ends the process or selects another physician. 

• If the HCO does not want to inactivate the physician, the HCO cancels the inactivation then ends 
the process or selects another physician. 
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Use Case: 



Use Cases. 
HCO User 
Management 



(HCO Begins A 
ProC8 ^ J 



Create, Modify, 







Inactivate 






f 




t 


Create 




Rnd (Modify, 
inactivate) 




Yes 
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Use Case: Pharma Sales Organization Management: Location Management 



Information Flow: 

Pharma user begins process. 

Pharma user decides to work on one of the following: market, area, region, district, territory. 
Pharma user decides to create, modify, or inactivate the kind of record they've selected. 

CREATE 

To create a sales territory, Pharma user: 

1 . Selects one or more drugs. 

2. Enters a zip code range. 

3. Enters any zip codes in the range that must be excluded. 

4. Assigns one or more HCOs (this is optional). 

5. Names the territory. 

To create a district, Pharma user 

1 . Selects one or more territories. 

2. Names the district. 

To create a region, Pharma user 

1 . Selects one or more district. 

2. Names the region. 

To create an area, Pharma user 

1 . Selects one or more regions. 

2. Names the area. 

To create a market, Pharma user 

1 . Selects one or more areas. 

2. Names the market. 

Pharma user reviews record. 

o If everything is correct, Pharma user confirms. 

o if modifications are necessary, Pharma user modifies record. 

Pharma user decides whether to create more records, 
o If yes, return to creating a record, 
o If no, end process. 

MODIFY 

To modify an existing record, Pharma user locates a location by name. 

All fields in a location record can be modified. 

o Pharma user reviews record. 

o If everything is correct, Pharma user confirms. 

o If modifications are necessary, Pharma user modifies record. 
Pharma user decides whether to modify more records. 

o If yes, return to selecting a location record. 

o If no, end process. 

INACTIVATE 

To inactivate an existing record, Pharma user locates a location by name. 
Pharma user can inactivate a location. No fields can be deleted. 
Pharma user reviews inactivation. 

o If the inactivation is confirmed, Pharma user either ends the process or selects another location. 
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If the Pharma user does not want to inactivate the location, the Pharma user cancels the inactivation then 
ends the process or selects another location. 



Use Case: 



Use Cases 
Pharma Sales 

Territory 
Management 





(Pharma Ends A 
Process J 
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Use Case: Pharma Sales Organization Management: Employees 

Information Flow: 

1 . Pharma user begins process. 

2. Pharma user decides whether to create, modify, or delete employee record. 
CREATE 

The following steps are used to create a new record: 

1 . The following information is required: 

• Name 

• Address 

• Phone 

• Cell phone 

• Pager 

• Fax 

• Email 

• Title 

2. If the employee is a sales rep, pharma user assigns sales rep to one or more territories. 

3. Pharma user reviews record. 

• If everything is correct, Pharma user confirms. 

• If modifications are necessary, Pharma user modifies record. 

4. Pharma user decides whether to create more records. 

• If yes, return to creating a record. 

• If no, end process. 

MODIFY 

The following steps are used to modify an existing record: 

■ Pharma user locates an employee by name. A sales rep can also be located by the territories 
assigned to them. 

1 . Pharma user reviews record. All fields in an employee record can be modified: 

• If everything is correct, Pharma user confirms. 

• If modifications are necessary, Pharma user modifies record. 

2. Pharma user decides whether to modify more records: 

• If yes, return to selecting an employee record. 

• If no, end process. 

INACTIVATE 

The following steps are used to inactivate an existing record: 

■ Pharma user locates an employee by name. A sales rep can also be located by the territories 
assigned to them. 

■ Pharma user can inactivate an employee. No fields can be deleted. 
Pharma user reviews inactivation: 

• . If the activation is confirmed, Pharma user either ends the process or selects another 
product. 

• If the Pharma user does not want to inactivate the employee, the Pharma user cancels the 
inactivation then ends the process or selects another employee. 
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Use Case: 



Use Case= 
Pharma Sales 
Representative 




Yes 



Create 
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Assign 
territory 




i 
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Assign 
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Modify 



Review 
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Find 
(Modify, 
Inactivate) 



Inactivate 



No 





25 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 



CI LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




